高可用的网站架构
互联网企业实现高可用架构设计的主要目的是保证服务器硬件故障时服务依然可用，数据依然完整并能够被访问，其主要手段是数据和服务的冗余备份及失效转移。一旦某些服务器宕机，就将服务切换到其他可用的服务器上，如果磁盘损坏，则从备份的磁盘或数据服务器读取数据。
一个典型的网站设计通常遵循如下分层架构：
各层具有相对独立性，上层依赖下层。应用层主要负责业务具体逻辑处理；服务层负责提供可复用的服务；数据层负责数据的存储与访问。中小型网站在具体部署时，通常将应用层和服务层部署在一起，数据层另外部署。
复杂的大型网站会有更细的划分粒度：
大型网站的分层架构和物理服务器的分布式部署使得位于不同层次的服务具有不同的可用性特点。宕机时产生的影响也不同，高可用的解决方案也不同。
位于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同对外提供服务，当负载均衡设备通过心跳检测等手段监控到某台应用服务器不可用时，就将其剔除，并将请求分发到其他可用的服务器上。服务层的服务器类似。
数据服务器上存储着数据，为了保证服务器宕机时数据不丢失，数据访问不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。
高可用的应用
应用层主要处理网站应用的业务逻辑，也称业务逻辑层，实现高可用需要的一个特点是应用的无状态性，也就是应用服务器不保存业务的上下文信息，而是仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。
通过负载均衡进行无状态服务的失效转移
不保存状态的应用给高可用的架构设计带来了巨大便利，因为所有服务器完全对等，可以将请求转移给任何一台可用的服务器而不会影响结果。
负载均衡实现服务器可用状态实时监控，自动转移失效任务，同时保证每个服务器上的负载相对平均(根据具体性能)，不至于超过负载。
应用服务器集群的Session管理
实际上很多业务是有状态的，如电子商务网站购物车等。Web应用将这些多次请求修改使用的上下文对象称为Session，在单机情况下，session可由部署在服务器上的web容器管理（如Jboss）。但在使用负载均衡的集群环境中，请求可能被分发到任何一台服务器上，情况要复杂很多。
集群环境下，session管理主要有一下几种手段：
- session复制
集群中所有服务器同步session对象。当集群规模很大时，负担很重。
- Session绑定
session绑定可以利用负载均衡的原地址Hash算法实现，负载均衡总是将来源于同一IP的请求分发到同一台服务器上（或Cookie信息）。这时负载均衡必须工作在HTTP协议层上。Session绑定也称为会话粘滞。
但是不符合系统高可用的要求，某台服务器宕机后，其上的session信息都会丢失。没有得到广泛使用。
- 利用Cookie记录session
将session记录放在客户端，每次请求服务器时，将session放在请求中发给服务器，服务器处理完请求后再将修改过的session响应发给客户端。
缺点是Cookie大小有限制，传输Cookie会影响性能。还有可能浏览器关闭Cookie支持等情况。但是因为其便利性，仍得到了广泛使用。
- Session服务器
利用独立部署的Session服务器统一管理Session，服务器每次读写Session时，都访问Session服务器。
实际上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。
高可用的服务
可复用的服务模块为业务产品提供基础公共服务，大型网站中这些服务通常独立分布式部署，被具体应用远程调用。可复用的服务和应用一有那个，也是无状态服务，因此可以使用类似负载均衡的失效转移策略实现高可用的服务。
除此之外，还有一下的几点高可用的服务策略：
分级管理
运维上将服务器进行分级管理，核心应用和服务使用更好的硬件。同时服务部署上也进行必要的隔离，避免故障的连锁反应，低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，高优先级的服务则需要部署在不同的屋里机上，核心服务和数据甚至需要部署在不同地域的数据中心。超时设置
在应用中设置服务调用的超时时间，一旦超时，通信框架就抛出异常，应用程序根据服务调度策略，可以选择继续重试或者转移请求。异步调用
应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
- 服务降级
如果网站遇到无法承受高并发访问，为了保证核心应用和功能的正常运行，可以对服务进行降级，一种手段是拒绝低优先级应用的调用，减少服务调用并发数，也就是拒绝服务，另一种是关闭部分不重要的服务，以节约系统开销，也就是关闭服务。
- 幂等性设计
有时会出现虚假的服务调用失败，比如服务完成超时，但是后面完成了操作，但是应用还是发出了一个新的请求。服务重复调用是无法避免的，因此需要在服务层保证重复调用和调用一次产生的结果相同，即服务具有幂等性。
有些服务天然具有幂等性，但有些不是，比如转账等，这时需要设置交易编号等信息进行服务调用有效性验证，以实现幂等性。
高可用的数据
不同于高可用的应用和服务，由于数据存储服务器上保存的数据不同，当某台服务器宕机时，数据访问请求不能任意切换到集群的其他机器上。
保证数据存储高可用的手段是数据备份和失效转移机制。数据备份是保证数据有多个副本，失效不会导致数据的永久丢失。失效转移保证一个数据副本不可访问时，可以快速切换访问数据的其他副本。
关于缓存的高可用，本质上其不是数据存储服务，缓存服务器宕机引起缓存数据丢失导致服务器负载压力过高应该通过其他手段解决，而不是提高缓存服务本身的高可用。
CAP原理
为了保证数据的高可用，往往需要牺牲另一个重要指标；数据一致性。
高可用的数据有如下几个层面的含义：
- 数据持久性：即数据不会丢失，需要将数据备份多个副本
- 数据可访问：在多份数据副本分别存放在不同设备情况下，如果一个损坏，就需要将数据访问切换到另一个设备上。如果这个过程不能很快完成（用户几乎没有感知），那么这段时间数据是不可访问的。
- 数据一致性：在数据有多个副本情况下，如果网络等出现故障，会导致部分副本更新成功，部分可能会失败，这时副本间的数据就会不一致。
CAP原理任务，一个提供数据服务的存储系统无法同时满足数据一致性（Consistency)、数据可用性（Availibility）、分区耐受性（Patition Tolerance,系统具有跨网络分区的伸缩性）。
在大型网站应用中，数据规模总是快速扩张的，因此可伸缩性即分区耐受性必不可少。规模变大以后，节点失效的可能也会变大，要想保证应用可用，就必须保证数据的可用性。所以在互联网应用中，通常会强化分布式存储系统的可用性和伸缩性，而在一定程度上放弃一致性。尽管如此，系统需要对分布式数据处理系统的数据不一致性进行弥补，以避免数据不正确。
具体数据一致性又可分为如下几点：
- 数据强一致：各个副本数据在物理存储总是一致的。
- 数据用户一致：数据在物理存储中的各个部分可能是不一致的，但是用户访问时，通过纠错和校验，可以确定一个一致且正确的数据返回给用户。
- 数据最终一致：较弱的一致性，物理存储可能是不一致的，用户访问也可能是不一致的，但是系统经过一段时间（较短的时间段）的自我恢复和修正，数据最终会达到一致。
因为难以满足数据强一致性，网站通常会综合成本技术，结合数据监控和纠错功能，使存储系统达到用户一致。
数据备份
备份分为冷备和热备。
冷备的有点是简单和廉价，但是不能保证数据最终一致，因为可能丢失上一次冷备后的更新，同时不能保证数据可用性，因为一般需要较长时间恢复数据。
所以需要热备，热备可以分为两种：异步热备方式和同步热备方式。
异步方式是指多份数据副本的写入操作异步完成，应用程序收到数据服务系统的写操作¥成功响应时，只成功了一份，存储系统会异步地写其他副本（这个过程有可能会失败）。通常先由主存储服务器（Master）写入第一份数据然后响应，然后通过异步线程将写操作数据同步到从存储服务器。
同步方式是指多份数据副本的写入操作同步完成。为了提高性能，通常需要并发的向多个存储服务器写入数据。没有主从之分，方便管理，但是响应速度慢。
关系数据库热备一般是Master-Slave同步机制，另外这一机制也可以通过读写分离改善数据库的性能，写操作只访问Master数据库，读操作只访问Slave数据库。
失效转移
失效转移由下面三部分组成：
- 失效确认
通常通过心跳检测和应用程序访问失败报告确认服务器是否宕机。对于访问失败报告，系统还需要再发送一次心跳检测进行确认。
- 访问转移
- 数据恢复
由于某台服务宕机，存储的副本减少，所以需要重新恢复足够的副本数。